home *** CD-ROM | disk | FTP | other *** search
- Path: news.iadfw.net!usenet
- From: Larry Weiss <lfw@iadfw.net>
- Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
- Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
- Date: Sun, 24 Mar 1996 10:06:57 -0600
- Organization: customer of Internet America
- Message-ID: <31557321.6A8B@iadfw.net>
- References: <1995Jul3.034108.4193@rcmcon.com> <4i862r$1evq@saba.info.ucla.edu> <64ss5$3F3RB@herold.franken.de> <314DADD4.3DE@oc.com> <4j3ohvINN4vu@keats.ugrad.cs.ubc.ca>
- NNTP-Posting-Host: dal08-29.ppp.iadfw.net
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.01 (Win16; I)
-
- Kazimir Kylheku wrote:
- >
- > The above are ones you wouldn't want to redefine anyway. I doubt you could
- > make a better strcpy() or abs() than compiler-generated inline code!
- > --
-
- You may just want or need learn how many invocations of that logic occur.
-
- Remember, I'm asking how does a hacker feel about the inability to depend on these
- calls actually executing an easily replaceable or patchable code segment.
- I suspect that a hacker would take your last sentence as a challenge, and
- then if he/she were good enough, well who knows?
-
- I do understand the software engineer's needs (although even in that domain I
- like to think that I can readily employ the memory leak-detector tools that rely on
- not inlined malloc() free() code generation). Although while wearing my
- engineer's cap, if there were really good runtime efficiency gains to be had
- by inlining those calls .... well it would be a tough decision. (and the problem
- there is with my 3rd party library code where the inline/not-inlined decisions
- are already imposed, either helping or restricting my leak-detector.
-